1. Field of the Invention
The present invention relates to Mobile Internet Protocol version 6 (Mobile IPv6) and more particularly to optimizing management of the mobility by increasing handover performance in Mobile IPv6.
2. Description of the Related Art
Mobile IP version 4 (Mobile IPv4, Mobile IP, MIPv4 or MIP) and the current version of Mobile IPv6 (MIPv6) are built to provide mobility to a host or Mobile Node (MN). The other nodes, usually referred to as Correspondent Nodes as (CN), are usually seen as fixed hosts. Reference is now made to the drawings where FIG. 1 shows a MIPv6 network architecture as suggested by the current MIPv6 specification found in an Internet Engineering Task Force (IETF)'s Request For Comment (RFC) number 3775, herein included by reference. As can be seen in FIG. 1, an IP network 100 comprises a MN 110 in communication with a CN 120 on a link 122. The link 122 is unlikely to be composed of only one direct physical connection, but rather represents a series of links between routing equipments transparently enabling the communication therebetween. The way the series of links is used to transport traffic between the MN 110 and the CN 120 is irrelevant as long as IP communication therebetween can be established.
The MN 110 has a permanently assigned home address valid in its home network 127, which home address is allocated upon initialization of the MN 110 in the home network 127. The MN 110 is further in communication with a Home Agent (HA) 130 located in its home network 127. Among other functionalities, the HA 130 keeps record of a foreign address of the MN 110 valid outside the home network 127. The foreign address is called Care-of-Address (CoA) in the context of MIPv6. The CoA assigned to the MN 110 changes in time as the MN 110 moves from one network to another. The record kept by the HA 130, referred to as binding in the context of MIPv6, ties the CoA to the home address. A binding between the home address and the CoA is also kept in the CN 120 for the purpose of reaching the MN 110. The HA 130 is also responsible for routing traffic received at the home address to the MN 110. The traffic received is forwarded by the HA 120 on a link 125 toward the MN 110.
In an attempt to diminish the pressure on the HA 130 and the link 125 between the HA 120 and the MN 110, Hierarchical Mobile IPv6 mobility management (HMIPv6) was developed. The last publicly available version of the HMIPv6 protocol is specified in the IETF's Internet Draft<draft-ietf-mipshop-hmipv6-04.txt>, herein included by reference, also referred to hereinafter as the HMIPv6 specification.
FIG. 2 shows an HMIPv6 network architecture as specified by the HMIPv6specification. In its simplest expression, the objective of HMIPv6 is to replace the MN 110 by an HMIPv6 domain 110′, thereby diminishing the need to update the binding maintained at the HA 130. In order to do so, the HMPv6 domain 110′ comprises a Mobile Anchor Point (MAP) 210. The MAP 210 could be seen as a local Home Agent in the HMIPv6 domain 110′. For the purpose of the example shown on FIG. 2, the MAP 210 is connected to an Intermediate Router IR1 220, which in turns connects to an Intermediate Router IR2 222 and an Intermediate Router IR3 224. An Access Router AR1 230 is connected to the IR1 220. An Access Router AR2 232 and an Access Router AR3 234 are both connected to the IR3 224. Various links 240 are used to route information between the nodes of the HMIPv6 domain 110′. Some further links 242 could also exist, but are not specified nor used in the HMIP6 specification (as shown by the dotted arrows of the links 242). The links 240 and 242 are usually wired links. The MAP 210 could also be connected to further intermediate routers and access routers, as shown by the dotted arrow 244. The MAP 210 is the entry point of the HMIPv6 domain 110′ and, as such, would be connected to the link 125 of FIG. 1 in lieu of the MN 110. FIG. 2 also shows a MN 112 entering the HMIPv6 domain 110′ in a first position A, and moving along to positions B and C. The MN 112 is connected to the AR1 230 via a link 250 while near position A, to the AR2 232 via a link 252 while near position B and to the AR3 234 via a link 254 while near position C. For illustrative purposes, all links are shown even if the MN 112 is closer to position B. The links 250 to 254 are usually wireless links.
FIG. 3 shows a nodal operation and flow chart of the actions and interactions between the MN 112 and the other nodes of the HMIPv6 domain 110′ when the MN 112 enters therein (step 310). Shortly after 310, the MN 112 receives a Router Advertisement (RtAdv) 314 containing information on the MAP 210 and the sender of the RtAdv. An RtAdv message is sent periodically by each of the Access Routers of the HMIPv6 domain 110′. The MN 112 could also actively request the RtAdv 314 through an optional Router Solicitation (RtSol) 312 if it is not received or not received in due time in view of the MN 112 configuration. The RtSol 312 is a message sent to the multicast address and to which the receiving access routers (e.g. the AR1 230 and the AR2 232) respond with an appropriate RtAdv. Upon reception of the RtAdv 314 from the AR1 230, the MN 112 configures a Local Care-of-Address (LCoA), a Regional Care-of Address (RCOA) (step 316) and performs a Duplicate Address Detection (DAD) on its LCoA to make sure that the address is not already in use in the HMIPv6 domain 110′. It has already been determined through experiences that a typical DAD 316 procedure for the LCoA takes more than 2000 ms in a typical HMIPv6implementation. The LCoA is valid under the AR1 230. In accordance with the HMIPv6specification, the LCoA is a concatenation of the first 64 bits of the AR1's 230 subnet prefix (obtained in the RtAdv 314) and another 64 bits value provided by the MN 112. The RCoA is valid under the MAP 210. In accordance with the HMIPv6 specification, the RCoA is a concatenation of the first 64 bits of the MAP's 210 subnet prefix (obtained in the RtAdv 314) and another 64 bits value provided by the MN 112.
After step 316, the MN 112 informs the MAP 210 of its newly configured LCoA and RCoA by sending a Local Binding Update (LBU) 318 addressed to the MAP 210. The LBU 318 will follow the appropriate links 240, being forwarded along the HMIPv6 topology by the routers on its way, up to the MAP 210. As specified by the HMIPv6 specification, the MAP 210 will then perform a DAD (step 320) to make sure that no other under its responsibility is currently using the RCoA proposed by the MN 112. It has already been determined through experiences that a typical DAD 320 procedure for one RCoA address takes around 20-30 ms in a typical HMIPv6 implementation. If the DAD 320 is positive (i.e. if the RCoA and the LCoA are not already in use), the MAP 210 registers the RCoA and LCoA in a local binding and takes the appropriate steps (i.e. BU to the HA 130, not shown on FIG. 3) to register the RCoA with the HA 130. To confirm the local binding, the MAP 210 further sends a Local Binding Acknowledgement (LBA) 322 addressed to the LCoA of the MN 112. Thereafter, the MAP 210 acts as a local HA and receives all packets addressed to the RCoA on behalf of the MN 112 and encapsulates and forwards them directly to the MN's 112 LCoA. This is noted on FIG. 3 with the double arrow marked as ‘Traffic’ 324.
According to the HMIPv6 specification, when the MN 112 moves toward B (step 330), the MN 112 needs to handover from the AR1 230 to the AR2 232. For instance, where the links 250-254 are wireless, the HMIPv6 specification does not strictly provides a threshold to decide on the moment where the MN 112 should initiate or respond to a network initiated handover procedure. However, a measure of the quality of the wireless communication between the MN 112 and the AR1 230 can be used as a decision basis. If the handover is initiated by the MN 112, an RtSol 332 is sent, to which an RtAdv 334 is received. The RtAdv 334 could also be the first message of the network initiated handover procedure if it is not sent in response to the RtSol 332, but the MN 112 always has the last word on when the actual LCoA is dropped in favor of a newly configured LCoA2 (step 336), at which time the MN 112, as specified by the HMIPv6 specification, performs a DAD to make sure the LCoA2 is not already in use (again, +2000 ms). The LCoA2 is valid under the AR2 232. In accordance with the HMIPv6 specification, the LCoA2 is a concatenation of the first 64 bits of the AR2's 232 subnet prefix (obtained in the RtAdv 334) and another 64 bits value provided by the MN 112.
After step 336, the MN 112 informs the MAP 210 of its newly configured LCoA2 by sending a Local Binding Update (LBU) 338 addressed to the MAP 210. The LBU 338 will follow the appropriate links 240, being forwarded along the HMIPv6 topology by the routers on its way, up to the MAP 210. The MAP 210 then registers the LCoA2 replacing the LCoA in the local binding. No update of the HA 130 is necessary at this point since the RCoA did not change. To confirm the local binding, the MAP 210 further sends a Local Binding Acknowledgement (LBA) 342 addressed to the LCoA2 of the MN 112. Thereafter, the MAP 210 acts as a local HA and receives all packets addressed to the RCoA on behalf of the MN 112 and encapsulates and forwards them directly to the MN's 112 LCoA2. This is noted on FIG. 3 with the double arrow marked as ‘Traffic’ 344.
The decision as to when the handover should be initiated or accepted by the MN 112 is critical since the traffic will stop reaching the MN 112 upon breakage of the connection with the AR1 220. Considering the delay introduced by the handover procedure (2000 ms only for the DAD procedure of step 336 added to the forwarding time between the MAP 210 and the MN 112), it can be readily anticipated that the presented solution is not viable in an expected typical HMIPv6 implementation. This is especially problematic for conversational voice applications since a delay longer than 250 ms prevents the application from being viable.
Considering the problem, the Fast Handover Procedure was seen as a potential solution if applied in the context of HMIPv6. The Fast Handover Procedure is specified in the IETF's Internet Draft <draft-ietf-mipshop-fast-mipv6-02.txt>, herein included by reference, also referred to hereinafter as the Fast Handover specification. The basic feature of the Fast Handover specification is to enable the AR1 220 currently serving the MN 112 to send information regarding neighboring Access Routers, thereby enabling a faster configuration of the LCoA2. The HMIPv6 specification provides a proposed adaptation of the Fast Handover specification in its appendix 1. FIG. 3B presents the adaptation in the context of the already developed example of FIG. 3.
On FIG. 3B, the step 330 of moving toward B is the starting point of the Fast Handover modified by the HMIPv6 specification. Thereafter, the MN 112 sends a Proxy RtSol (PrRtSol) 352 to the AR1, which responds thereto with a Proxy RtAdv (PrRtAdv) 354 on behalf of the AR2 232. The PrRtAdv 354 could also be sent spontaneously from the AR1 220, but the threshold for such an event is not specified. At about the same time the PrRtAdv 354 is sent, the MAP 310 decides (step 358) that a handover needs to take place for the MN 112 from the AR1 230 to the AR2 232. Unfortunately, no guidance as to how the MAP 210 could take such a decision 358 was understood in the Fast Handover specification or, more pertinently, in the HMIPv6 specification. If there is a mechanism specified, it could not be understood to enable the MAP 210 to take the decision 358 and the MAP 210 is not positioned in the HMIPv6 topology to efficiently obtain information on the quality of the communication between the AR1 230 and the MN 112. Presuming that the decision 358 could be somehow taken at the appropriate moment (i.e. at about the same time the PrRtAdv 354 is sent), the MAP sends a Handover Initiate (hi) addressed to the AR2 to inform the node of the incoming MN 112. The AR2 further replies with a Handover Acknowledge (hack) 362 specifying if the handover can take place. If the hack 362 is positive (i.e. handover can take place), the MAP 210, upon reception thereof, start tunneling traffic received on LCoA to LCoA2. This is noted on FIG. 3B with the double arrow marked as ‘Traffic’ 364.
At some point after reception of the PrRtAdv 354, the MN 112 should decide to proceed with the handover from the AR1 230 to the AR2 232. However, again, no threshold is specified. Whenever the decision is taken, the MN 112 configures a LCoA2 (step 356) in a similar way to what was already presented, concatenating the first 64 bits of the AR2's 232 subnet prefix (obtained this time from the PrRtAdv 354 instead of the RtAdv 334) and another 64 bits value provided by the MN 112. At step 356, the MN 112, as specified by the HMIPv6specification, also performs a DAD to make sure the LCoA2 is not already in use (again, +2000 ms). The MN 112 then sends a Fast local Binding Update (FBU) 370 within the HMIPv6 topology up to the MAP 210. The MAP 210 then updates its Local Binding to change the LCoA for the LCoA2 before sending a Fast local Binding Acknowledgement (FBA) 372.
This Fast Handover in the context of HMIPv6 alternative has the advantage of allowing traffic 364 before the exchange of the FBU 368 and the FBA 372, but still uses the DAD in step 356 (+2000 ms) to validate the LCoA2. In cases where the LCoA2 is not valid, the handover is not performed properly and the situation is reverted back to the inadequate procedure shown on FIG. 3. Another problem of the procedure shown on FIG. 3B lies, however, in the synchronization between the decision to handover of the MN 112 (step 356) and the decision of the MAP 210 to initiate the handover (step 358). As mentioned earlier, the mechanism necessary to inform the MAP 210 of the relevance of a handover of the MN 112 from the AR1 230 to the AR2 232, if ever specified in either of the HMIPv6 or Fast Handover specifications, was not understood. Furthermore, the MAP 210 is not positioned in the HMIPv6 topology to efficiently obtain information on the quality of the communication between the AR1 230 and the MN 112, and moving the MAP 210 closer to the MN 112 would substantially reduce the advantage of the MAP function as such (i.e. to reduce the signaling toward the HA 130).
As can be appreciated, there is a need for a handover solution, compatible with the HMIPv6 topology, that is efficient enough to support requirements of various applications such as conversational voice applications or other time dependent applications.